AWS入門ブログリレー2024〜AWS Site-to-Site VPN編〜

こんにちは、なおにしです。

当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の9日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今回のテーマは『AWS Site-to-Site VPN』です。

AWS Site-to-Site VPNの概要

AWS Site-to-Site VPNは、仮想プライベートネットワーク(VPN)技術を使用してAWSクラウドと別のネットワークとの間に安全でプライベートなトンネルを確立するためのサービスです。

AWSではVPNを用いた接続方法として「AWS Site-to-Site VPN」と「AWS Client VPN」の2種類を提供しています。 前者はネットワークとAWSを接続するため、VPN接続先(AWS)に対するクライアント側はネットワーク機器(もしくはゲートウェイ機能を有するサーバやサービス)となります。
後者は本記事では取り上げませんが、クライアント側はノートPCのような個々のデバイスとなります。このため、クライアント側にVPNクライアントソフトをインストールして使う形です。

接続方式について

一般的なVPN接続には以下のように様々な種類の接続方式や技術要素があります。下記はネットワークレイヤーなどを意識せずに列挙していますが、例えばWindows OS標準で提供されているVPN接続だとL2TP/IPsecのように要素を組み合わせて用いられていたり、ネットワークベンダーがIPsecを拡張して独自仕様のVPN接続方式を提供していたりもします。

• L2TP
• OpenVPN
• SSL-VPN
• IPsec
• WireGuard etc...

したがって、VPN接続では接続方式に応じてクライアント側も適切に設定する必要があります。

上記の前提を踏まえ、AWS Site-to-Site VPNではIPsec接続がサポートされています。
このためVPN接続を行うクライアント側(カスタマーゲートウェイ)において、AWS Site-to-Site VPNが提供するIPsecの各種パラメータ(トンネルオプション)を適切に設定することでVPN接続が可能になります。設定できるトンネルオプションの一覧はこちらに記載があります。

また、ルーティング方法としては動的ルーティングと静的ルーティングの両方をサポートしています。動的ルーティングでサポートされているプロトコルはBGP(Border Gateway Protocol)です。カスタマーゲートウェイのデバイスが対応していないといった特別な要件がない場合はBGPの設定が推奨となっています。
BGPを設定する場合にはASN(Autonomous System Number/自律システム番号)なども設計/設定する必要があります。

接続先(AWS側)について

カスタマーゲートウェイの接続先(ターゲットゲートウェイ)として選択可能な項目は以下の3つです。

• 仮想プライゲートゲートウェイ(Virtual Private Gateway / VGW)
• トランジットゲートウェイ(Transit Gateway / TGW)
• 関連付けなし(Cloud WAN)

使い分けとしてはネットワーク規模( VGW < TGW < Cloud WAN )に応じて選択するイメージです。
特定のVPCに対して接続するのみで問題ない小規模ネットワーク環境であれば仮想プライベートゲートウェイを、リージョン内で複数VPCを相互に接続するためにトランジットゲートウェイを用いているような環境であればトランジットゲートウェイを、リージョンをまたいでトランジットゲートウェイ同士をCloud WANで接続しているような環境であれば関連付けなしを選択します。

また、後述の利用料金やクォータで触れますが、ターゲットゲートウェイの種類に応じてVPN接続時に選択できるオプションも異なってきます。

やってみた

オンプレ(自宅)に少し古いFortiGate(60D、ファームウェア: v5.4.4)があったので実際にSite-to-Site VPNでVPCと接続してみました。
このため構成としてはこちらと同じくシンプルになるため、図も引用させていただきました。

接続の流れは概ねドキュメントの入門チュートリアルに基づいて行います。

まず、AWS マネジメントコンソールから[VPC] - [カスタマーゲートウェイ]を選択してカスタマーゲートウェイを作成します。

オンプレのFortiGateをカスタマーゲートウェイとして登録します。
ASNについては今回は「65000」を設定します。プライベートASとして定義されている「64512～65534」の間から選択しています。
IPアドレスはカスタマーゲートウェイのグローバルIPアドレスを設定します。残念ながら自宅は固定IPアドレスではないため設定時点で確認したIPアドレスで検証しました。なお、IPアドレスしか登録できないので例えばDDNSを使っていたとしても動的な変更に対応させることはできません。
固定IPアドレスが準備できない場合はプライベート証明証を使用することも可能ですが、それなりに別途料金が発生しますのでご注意ください。

以下のように利用可能なカスタマーゲートウェイとしてすぐに登録されます。

続いてターゲットゲートウェイとなる仮想プライベートゲートウェイ(VGW)を作成します。

ASNは[AmazonデフォルトASN]を選択します。実際の番号は「64512」となります。ターゲットゲートウェイとカスタマーゲートウェイのASNはそれぞれ異なる番号を設定するため、[AmazonデフォルトASN]を選択する場合はカスタマーゲートウェイ作成時に「64512」以外を設定しておく必要があります。

以下のように「デタッチ済み」の状態で作成されました。なお、カスタマーゲートウェイおよび仮想プライベートゲートウェイを作成した現在の状態ではまだ料金は発生しません。

続いて、作成した仮想プライベートゲートウェイをVPCへアタッチします。

1〜2分ほど待つと状態が「アタッチ済み」に変わりました。

アタッチ先のVPCで使用しているルートテーブルを開き、[ルート伝播]タブを選択します。先ほどアタッチした仮想プライベートゲートウェイが表示されています。アタッチ直後はルートの伝播が[いいえ]になっているため[ルート伝播の編集]を選択します。

[有効化]にチェックをして保存します。

それではVPN接続を作成します。

これまでに作成した仮想プライベートゲートウェイとカスタマーゲートウェイが選択できるようになっています。ルーティングオプションは今回は[動的(BGP が必要]を選択します。　　 また、スクリーンショットには含めていませんがその他にトンネルごとのオプションも設定可能です。特に[トンネルのメンテナンス]という項目については実際にAWS Site-to-Site VPNで運用を始めるのであれば注意が必要なので、詳細はこちらをご参照ください。

VPN接続が作成されました。今回は状態が[利用可能]になるまでは3分ほどかかりました。 トンネルが2つ作成されていますが、まだFortiGateの設定を全くしていないのでもちろんステータスは[ダウン]の状態です。そこで、FortiGateを設定するためのサンプル設定ファイルをダウンロードできます。

以下のようにカスタマーゲートウェイデバイスの製造元に応じた設定のサンプルを選択できます。

今回はデバイスがFortiGate(60D、ファームウェア: v5.4.4)なので以下のとおり選択しました。なお、[IKEバージョン]については[FortiOS 6.4.4+ (GUI)]を選択しないと[ikev2]を選択できなかったため、今回は[ikev1]で設定を進めます。

設定をテキストエディタで開いてみると以下のように設定方法が記載されています。

! Amazon Web Services
! Virtual Private Cloud

! AWS utilizes unique identifiers to manipulate the configuration of
! a VPN Connection. Each VPN Connection is assigned an identifier and is
! associated with two other identifiers, namely the
! Customer Gateway Identifier and Virtual Private Gateway Identifier.
!
（以下省略）

あくまでサンプルの設定方法が記載されたテキストであって、そのまま各種デバイスに読み込ませることが可能なコンフィグファイルではありません。さらに上記のダウンロード画面に記載のとおり、実際には設定の変更が適宜必要となります。

今回ダウンロードした設定ファイルの章立ては以下のとおりでした。

• IPSec Tunnel #1
  • #1: Internet Key Exchange (IKE) Configuration
  • #2: IPSec Configuration
  • #3: Tunnel Interface Configuration
  • #4: Border Gateway Protocol (BGP) Configuration
  • #5 Firewall Policy Configuration
• IPSec Tunnel #2
  • #1: Internet Key Exchange (IKE) Configuration
  • #2: IPSec Configuration
  • #3: Tunnel Interface Configuration
  • #4: Border Gateway Protocol (BGP) Configuration
  • #5 Firewall Policy Configuration

したがって、2つのトンネルを順番に設定する内容となっています。IPsecの事前共有キーなども本ファイルに直書きされているため、取り扱いにはご注意ください。

今回は検証のためにサンプルの設定ファイルに記載の内容をそのまま進めてみました。CLI操作がひたすら続く作業となるのでステップバイステップの説明は省略しますが、各設定ごとのendコマンドなどを補足しつつ概ね記載どおりの内容でVPN接続ができることを確認できました。 以下、設定ファイルのままでは適用できなかった部分となります。

• phase1-interfaceおよびphase2-interfaceの命名
  • 設定ファイルではVPN IDがそのまま記載されているが「Name must be shorter than 15 chars, best if shorter than 12」という注意書きのとおり変更が必要
• set dpd enable
  • enableという値を設定できないためデフォルト値(on-demand)のままで変更無し
• VDOMを構成していない場合は該当する設定は不要

FortiGateのファイアウォールポリシーまで設定が完了すると2つのトンネルのステータスが[アップ]に変わったのでルートテーブルを確認します。仮想プライベートゲートウェイをターゲットにしたルートが追加されています。

上記のままではデフォルトルートがインターネットゲートウェイと合わせて2つ存在する状態になっています。VPCからの接続を全てオンプレ側に転送するのであればインターネットゲートウェイへのデフォルトルートを削除するだけで問題ありませんが、特定のルートのみオンプレに向ける場合は修正が必要です。

上記のようにデフォルトルートが伝播される挙動は、設定ファイルにも以下のとおり記載があります。

! Your Customer Gateway may announce a default route (0.0.0.0/0) to us.
! This is done using prefix list and route-map in Fortigate.

修正するのであれば「capability-default-originate」を[disable]に設定の上、アドバタイズしたいプレフィックスを追加します。プレフィックスの追加方法についても以下のとおり設定ファイルに記載があります。

! To advertise additional prefixes to Amazon VPC, add these prefixes to the 'network'
! statement and identify the prefix you wish to advertise. Make sure the prefix is present
! in the routing table of the device with a valid next-hop. If you want to advertise
! 192.168.0.0/16 to Amazon, this can be done using the following:

つまり、設定する際はFortiGateで実際に存在するプレフィックスを指定しないとアドバタイズされません。サンプルでは「192.168.0.0/16」を追加でアドバタイズする旨が記載されていますが、ForiGate側に「192.168.0.0/16」が存在しない場合はアドバタイズされず、ルートテーブルに伝播されないことにご注意ください。

上記の修正を行うと、以下のように特定のプレフィックのみを伝播させることができます。

VGWをアタッチしたVPCに存在するEC2に対してオンプレ側の端末からpingを送ると、実際にオンプレ側のIPアドレスから受信していることを確認できます。なお、EC2のセキュリティグループは事前に設定済みです。

FortiGateでNATを有効化するとどうなるのか確認してみました。

同様にEC2に対してオンプレ側の端末からpingを送ると、以下のようになりました。

上記のIPアドレスはVPN接続設定の[内部 IPv4 CIDR]の[Tunnel 1]で表示されているIPアドレスに一致します。このため、FortiGate側でNATを有効化する場合は、こちらのIPアドレスからの通信を許可するようにセキュリティグループを設定する必要があります。

AWS Site-to-Site VPNの利用料金

AWS Site-to-Site VPNでは以下の2種類の料金が発生します。

• AWS Site-to-Site VPN 接続料金
  • サイト間 VPN 接続ごとに USD 0.048/時間（東京リージョンの場合）
• データ転送アウト料金
  • USD 0.09/GB
  • Amazon EC2 からのデータ転送アウトと同じ料金体系
    • 最初の100 GB は無料
    • データ転送インは無料

したがって、AWSの料金ページに記載の例を日本円(150円/USDと仮定)で表現すると以下のとおりです。

（例）

アジアパシフィック(東京) で、Amazon VPC への AWS Site-to-Site VPN 接続を作成したとします。この接続は 30 日間、1 日 24 時間アクティブです。この接続で 1,000 GB をイン、500 GB をアウトに転送します。

• AWS Site-to-Site VPN 接続料金：5,184円/月
  • 24時間 × 30日 × USD 0.048/時間 × 150円/USD
• データ転送アウト料金：5,400円/月
  • ( 500GB - 100GB ) × USD 0.09/GB × 150円/USD

合計：10,584円/月 (税抜)

つまりデータ転送アウトが月に100GBまでなら、AWS Site-to-Site VPN 接続料金の5,184円のみで維持することができます。
それでも高い！という場合はEC2のように使う時だけ起動するといった運用を考えたくなりますが、こちらの記事にあるとおりSite-to-Site VPN 接続がどのような状態だと料金が発生するのかということに注意する必要があります。
記載のとおり、具体的には以下のような状態でも料金が発生します。

このため、AWS Site-to-Site VPN 接続料金の発生を抑止するのであれば、カスタマーゲートウェイとの接続を切断するのではなく、Site-to-Site VPN 接続設定自体を削除する必要があります。設定を削除すると外部IPアドレスや事前共有キーも変更されるため、再度AWS Site-to-Site VPN 接続を作成する場合はカスタマーゲートウェイ側でも再設定が発生します。

その他にもアクセラレーションを有効化した高速VPN接続ではAWS Global Acceleratorなどに関わる料金も加算されますが、本記事では割愛します。
高速VPN接続はサイト間接続用のターゲットゲートウェイのタイプが「Transit Gateway」または「AWS Cloud WAN」である場合に有効化できます。
つまり本記事で検証した構成のように「仮想プライベートゲートウェイ(VGW)」がターゲットゲートウェイのタイプである場合は、高速VPN接続を選択することができません。

AWS Site-to-Site VPNのクォータ

公式ドキュメントでまとまっていますのでご参照ください。

特記事項としては、例えば以下のような制限がありますのでご注意ください。

• 動的ルートと静的ルートのそれぞれの上限数はクォータの引き上げリクエストができない
• 最大送信単位 (MTU)においてジャンボフレームはサポートされていない
• パスMTU 検出(Path MTU Discovery)によるMTUの自動設定はサポートされていない

その他にも全体的な制限として以下の記載があります。

• 仮想プライベートゲートウェイ(VGW)がターゲットゲートウェイのタイプであるVPN接続の場合、IPv6トラフィックはサポートされない
• VPCとオンプレミスネットワークのCIDRブロックは重複しないことを推奨

まとめ

「クラウドが気になっているけど現行システムはオンプレで稼働している」という状況の方はまだまだ大勢いらっしゃると思います。
特に独自の社内システムといった場合、通信の暗号化対応が難しいからローカルネットワーク内で運用している→でもハードウェアの老朽化が進んでいてそろそろ対応が必要→そのままオンプレでリプレースしても良いけどクラウドも気になっている...といったケースもあるかもしれません。
オンプレとクラウドをつなぐ手段としてはAWS Direct Connect もありますが、そこまで大掛かりに取り組む前にまずはシステムの一部をオンプレからクラウドに移行して検証してみたいといった要望もあるかと思います。

そういった時にAWS Site-to-Site VPN を使用することで、既存ネットワークとAWSをつなげて試してみるというアプローチも可能であることを、本記事でお伝えすることができたら幸いです。

終わりに

以上、『AWS 入門ブログリレー 2024』の9日目のエントリ『AWS Site-to-Site VPN』編でした。 次回、4/3は弊社たかやまによる「AWS Security Hub編」の予定です！

参考

• AWS Site-to-Site VPN ユーザーガイド
• 【AWS Black Belt Online Seminar】 AWS Site-to-Site VPN) (PDF)
• 【AWS Black Belt Online Seminar】 AWS Site-to-Site VPN (YouTube)
• AWS Site-to-Site VPN 接続のトンネルエンドポイントのライフサイクル制御を使ってメンテナンスを保留してみた
• Site-to-Site VPNは、VPNが非アクティブでも料金が発生するのか？